> On Mon, 28 Nov 1994, Gene Spafford wrote: > > > > > I think that the biggest pro of full disclosure, is that it get's people > > > off their butts and gets a good solution or patch that much faster. > > > > I have yet to see evidence of this. Based on my conversations with personnel > > at various computer companies, the only thing full disclosure seems to do is > > (sometimes) encourage them to release bug fixes without quite as much testing. > > This sometimes leads to patches that don't completely fix the problem. That > > is not a "good solution." > > this is an excellent argument for using one of the free unix > systems. the support team response time is much better. if you have the > knowlege and ability, you can fix it yourself. Those "if" qualifications are quite a bit bigger than you may realize. I regularly give tutorials to the people who run major computer centers and they are now switching over to Unix. They don't know C, don't know Unix, and are responsible for getting the plant moved over to Unix. They aren't allowed to use freeware or shareware (insurance and legal staff won't allow it) even if they knew how, which they don't. They often aren't on the net and don't plan to get Usenet groups even if they do connect, so they have no contact with "support team[s]" for free unix. Then there are others, like myself, who are using hardware that is not adequately supported by any free versions of Unix. Or (again like me), my software is supported by a paid staff and not by myself. They are using a commercial offering because it is consistent across about 10 different machine architectures in the department. Actually, it is possible to get source to commercial versions of Unix, if you think it is worth the expense. Therefore, the argument doesn't apply solely to "free" versions of Unix. Large corporations with a concern for security do pay for source licenses for precisely this reason. (Rhetorical question: I wonder how much of the "full disclosure" pressure is from people using "free" versions of Unix who hear about a bug and demand the details to know if it applies to their systems? They're getting what they [didn't] pay for, but are agitating for more information at the potential expense of endangering other users.) If we are concerned about improving the state of computer security for *everyone*, we need to give careful thought to the needs and abilities of the entire use community -- not just the ones who are comfortable with kernel hacking, free software, and the Internet. On the other hand, if all we are concerned about is our own personal security picture, then having sources is the way to go, assuming we have time and talent to pursue them. (But note how many people have tried to program around the race condition in /bin/mail and gotten it wrong -- including the pros inside Sun, and many people on this list who had access to source code.) I'm not trying to dispute your statement -- merely pointing out that most people don't understand all the complexities of the situation behind issues of disclosure and patches. Or, they don't care, because they only are concerned with getting fixes for themselves. I'm also not trying to reopen the debate about full vs. partial vs. no disclosure. I'd like to see some hard evidence for things, though, and *not* debate. Even my experience has been anecdotal (but I believe that it is more representative of the true user community than these lists are). Statements to the effect that "policy X produces patches faster than policy Y" should be backed up by testable data. Otherwise, they fall in the category of faith healing, diet aids, and sightings of Elvis -- the observer may believe it is true, but there is no controlled way to demonstrate it to skeptical observers in a general setting. Cheers, --spaf in his professor mode :-)